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DETAILED ACTION 



1 



The IDS of 6/19/02 was received and considered. 



2 



Claims 1-21 are pending. 



Claim Objections 



3. Claims 3, 18, 13 & 18-20 are objected to because of the following informalities: 

a. Regarding claim 3, "a network address" (line 22) is believed to be "a network 
address translator" and will be treated accordingly. 

b- Regarding claim 8, "client of Claim 2" (line 19) is believed to be "client of Claim 
7" and will be treated accordingly, 

c. Regarding claim 13, "the heading" (line 8) is believed to be "the header" and will 
be treated accordingly. 

d. Regarding claims 18 & 19, the claims are believed to depend from claim 17 rather 
than claim 16, and will be treated accordingly. 

e. Regarding claim 20, "the first end port" (line 20) should be replaced with "the 
first end point" and will be treated accordingly. 

Appropriate correction is required. 



Claim Rejections - 35 USC §112 



4. 



The following is a quotation of the second paragraph of 35 U.S.C. 112: 



The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 
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5. Claim 1 recites the limitations "the client" in line 5. There is insufficient antecedent basis 
for this limitation in the claim. 

6. Claim 3 recites the limitations "the network address translator" in lines 22-23. There is 
insufficient antecedent basis for this limitation in the claim. 

7. Claim 6 recites the limitations "the server" in line 3 and "the external IP addresses" in 
lines 11-12. There is insufficient antecedent basis for these limitations in the claim. 

8. Claim 9 recites the limitation "the communication session". There is insufficient 
antecedent basis for this limitation in the claim. 

9. Claim 12 recites the limitations "the server" in line 16 and "the client" in line 16. There 
is insufficient antecedent basis for these limitations in the claim. 

10. Claim 14 recites the limitation "the client external IP address" in lines 14 & 18. There is 
insufficient antecedent basis for this limitation in the claim. 

11. Claim 14 is rejected under 35 U.S.C. 1 12, second paragraph, as being incomplete for 
omitting essential steps, such omission amounting to a gap between the steps. See MPEP 

§ 2172.01. The omitted steps are: the readdressing of the client internal IP address with the 
client external IP address. 

12. Claim 16 recites the limitation "the server internal IP address in line 30. There is 
insufficient antecedent basis for this limitation in the claim. 
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13. Claim 17 recites the limitations "the server internal IP address" in lines 8-9 and "the 
server external IP address" in line 13. There is insufficient antecedent basis for these limitations 
in the claim. 

14. Claim 19 recites the limitation "the client internal IP address" in line 29. There is 
insufficient antecedent basis for this limitation in the claim. 

15. Claim 20 recites the limitation "the client internal IP address" in line 29. There is 
insufficient antecedent basis for this limitation in the claim. 

16. Claim 20 is rejected under 35 U.S.C. 1 12, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. The claim is indefinite as to whether "a control channel" (line 4) is the same 
control channel as referred to in line 17. If the two are the same channel, line 17 should include 
"the control channel" in place of "a control channel". For the purposes of this Office Action, line 
17 will be read as "external network in the control channel; *\ 

17. Claim 21 is rejected under 35 U.S.C. 112, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. It is unclear how a "signal", "computer storage medium" and "modified dual 
channel command" are related. A computer storage medium is an apparatus where a command 
is performed in a method. 



Claim Rejections - 35 VSC §101 
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18. 35 US.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or 
any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 

19. Claim 21 is rejected under 35 U.S.C. 101 because the claimed invention is directed to 
non-statutory subject matter. The subject matter being claimed is a "signal" which is none of a 
process, machine, manufacture or composition of matter. 

Claim Rejections - 35 USC §102 

20. The following is a quotation of the appropriate paragraphs of 35 U.S.C, 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent imless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of appUcation for patent in the United States. 

21. Claim 14 is rejected under 35 U.S.C. 102(b) as being anticipated by "Distributed 
Network Access Translation" by Borella et al. (Borella). Borella discloses encoding a port 
command including a client internal IP address/Src of outer header and client port number/Src 
port (page 1 5, first Fig.), generating a dual channel communication packet having a header and a 
data payload (page 15) with a server external IP address/Des of inner header, server port 
number/Dst port, client internal IP address/Src in outer header and client port number/Src port 
(page 15). The packet is sent to the server and the port command is decoded/read (page 15). 
Borella discloses modifying the decoded port command by overriding the client internal IP 
address/Src in outer header with the client external IP address/Src in inner header and 
establishing a data socket (data flow) between the server and the client (page 15). 
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Claim Rejections - 35 USC §103 

22. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

23. Claims 1-4, 6-9 & 17-20, as best understood, are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Network Security Essentials. Applications and Standards by Stallings in 
view of "The IP Network Address Translator (NAT)" by Egevang et al. (Egevang) in view of "IP 
Security and NAT: Oil and Water?" by Phifer in further view of "Firewall-Friendly FTP" (RFC 
1579) byBellovin. 

Regarding claims 1 & 3, Stallings discloses a communication packet having a 
header/outer header and a data payload/original packet, the data payload including a port 
command/original packet including a client internal IP address/source address (page 179, Fig. 
6.9(b) & page 180) and a client port number/port (contained in an TCP/IP header) and a 
header/outer and inner packet (page 179). Stallings further discloses decoding the port 
command/original packet (page 180, step 3). Stallings lacks a header having a client external IP 
address and a translation module operable to retrieve the client external IP address fi*om the 
header and to generate a modified port command including the external IP address, where the 
server is operable to establish a second channel based on the modified port command. However, 
Egevang teaches a protocol (NAT) to reduce IP address depletion (page 1) (NAT is commonly 
used today and is incorporated with routers, as in Fig, 2). NAT states that when sending a packet 
from a source behind a router (Stub A) to a destination behind another router (Stub B), a packet 
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will contain Stub A's internal address and Stub B's global address (Fig. 2), Stub A's local 
address will be readdressed to the global address at Stub A's router and sent to Stub B's global 
address (Fig. 2). At Stub B's router, the destination address will be replaced with Stub B's 
internal address and forwarded to stub B and a similar method is used in the reverse direction 
(Fig. 2 and page 3). Therefore, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to combine the teachings of Stallings and Egevang to use 
IPSec with NAT and route the packet according to the same transformations as occurred between 
Stubs A and B. One of ordinary skill in the art would have been motivated to perform such a 
modification because NAT is known to reduce the problems associated with IP address depletion 
(page 1) and because a skilled artisan in network architecture knows of NAT's widespread use 
and acceptance. In combination, a client external IP address (translated at the stub router from 
the internal address) is included in the header. Further, Phifer teaches that to avoid problems 
with locating endpoints in IPSec, one can perform network address translation outside IPSec 
(page 2). In doing so, the inner packet's internal client address is replaced with the client's 
external address (page 2). Therefore, it would have been obvious to one having ordinary skill in 
the art at the time the invention was made to decode the port command and replace the client 
internal IP address with the client external IP address found in the header (NAT translating 
outside IPSec). One of ordinary skill in the art would have been motivated to perform such a 
modification to avoid problems with locating endpoints in IPSec, as taught by Phifer (page 2). 
Stallings, as modified above, lacks a second channel being established and lacks specifically a 
server performing the functions. However, Bellovin teaches that FTP uses two channels, a 
control channel and a data channel where the control channel is used to negotiate the connection 
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and the data channel uses that second connection to transfer data (pages 1-2). Therefore, it 
would have been obvious to one having ordinary skill in the art at the time the invention was 
made to enable an FTP server to perform the functions described above and to establish a second 
connection based on the modified port command. One of ordinary skill in the art would have 
been motivated to perform such a modification to support the well-known FTP protocol, as 
taught by Bellovin (pages 1-2). 

Regarding claim 2, the examiner takes Official Notice that packet filters (hardware and 
software) are old and well established in the art of computer security as a method of preventing 
potentially harmful traffic from entering a network. Therefore, it would have been obvious to 
one having ordinary skill in the art at the time the invention was made to include a packet 
filtering server firewall in the server. One of ordinary skill in the art would have been motivated 
to perform such a modification to prevent potentially harmful traffic from entering the server. 
This advantage is well known to those skilled in the art. 

Regarding claim 4, Stallings, as modified above, discloses FTP communication 
conducted over a secure tunnel (Stallings, page 179 & Egevang, pages 1-10). 

Regarding claim 6-9, the claims are substantially equivalent to claims 1-4, respectively. 
Therefore, claims 6-9 are rejected under similar rationale. 

Regarding claim 17, Stallings discloses encoding a port command/original packet 
including a client internal IP address/source address (page 179, Fig. 6.9(b)) and a client port 
number/port (contained in an TCP/IP header), generating a communication packet having a 
header/outer header and a data payload/original packet, the data payload including the encoded 
port command/original packet (Fig. 6.9(b)), transmitting the packet between a server/destination 
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and the client/source (page 180), decoding the port command/original packet (page 180, step 3) 
and establishing a data socket (data flow) between the server/destination and the client/source 
(page 180, step 3). The header includes a server external IP address/destination firewall address 
and a server port (TCP header) and a client internal IP address/source address and port (TCP 
header) (pages 180-181). Stallings lacks explicitly overriding the client internal IP 
address/source address within the decoded port command/original packet with the client external 
IP address retrieved from the header. However, Egevang teaches a protocol (NAT) to reduce IP 
address depletion (page 1) (NAT is commonly used today and is incorporated with routers, as in 
Fig. 2). NAT states that when sending a packet from a source behind a router (Stub A) to a 
destination behind another router (Stub B), a packet will contain Stub A's internal address and 
Stub B's global address (Fig. 2). Stub A's local address will be readdressed to the global address 
at Stub A's router and sent to Stub B's global address (Fig. 2). At Stub B's router, the 
destination address will be replaced with Stub B's internal address and forwarded to stub B and a 
similar method is used in the reverse direction (Fig. 2 and page 3). Therefore, it would have 
been obvious to one having ordinary skill in the art at the time the invention was made to 
combine the teachings of Stallings and Egevang to use IPSec with NAT and route the packet 
according to the same transformations as occurred between Stubs A and B. One of ordinary skill 
in the art would have been motivated to perform such a modification because NAT is known to 
reduce the problems associated with IP address depletion (page 1) and because a skilled artisan 
in network architecture knows of NAT' s widespread use and acceptance. Further, Phifer teaches 
that to avoid problems with locating endpoints in IPSec, one can perform network address 
translation outside IPSec (page 2). In doing so, the inner packet's internal client address is 
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replaced with the dient*s external address. Therefore, it would have been obvious to one having 
ordinary skill in the art at the time the invention was made to decode the port command and 
replace the client internal DP address with the client external IP address (NAT translating outside 
IPSec). One of ordinary skill in the art would have been motivated to perform such a 
modification to avoid problems with locating endpoints in IPSec, as taught by Phifer (page 2). 
As modified, Stallings lacks "transmitting a passive command to the server". However, Bellovin 
teaches that using the PAS V (passive command) to initiate an FTP session reduces problems 
associated with FTP through firewalls (page 1). Therefore, it would have been obvious to one 
having ordinary skill in the art at the time the invention was made to transmit a passive 
command/PASV to the server. One of ordinary skill in the art would have been motivated to 
perform such a modification to reduce problems associated with FTP communication through 
firewalls, as taught by Bellovin (page 1). 

Regarding claims 18 & 19, Stallings, as modified above, discloses readdressing the client 
internal IP address within the header with the client external IP address at a client firewall and 
readdressing the server external IP address within the header with the server internal IP address 
at a server firewall (Stallings, page 183, Fig. 6.10(b) & Egevang, page 3). 

Regarding claim 20, Stallings discloses establishing a channel between a server and a 
client (page 183, Fig. 6. 10(b)), identifying a first end point/inner packet at a first one of a server 
and a client (two hosts), the first end point including a first portion/destination and a second 
portion/source (page 180), encoding the first end point in a secure format (encapsulate with new 
IP header) (page 180), transmitting the transmission packet over the external network in the 
channel (page 180, step 2) and receiving the transmission packet at the other client or server 
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(page 180, step 3). Stallings lacks explicitly translating the private address in the address header 
into a public address for transmitting over the external network. However, Egevang teaches a 
protocol (NAT) to reduce IP address depletion (page 1) (NAT is commonly used today and is 
incorporated with routers, as in Fig. 2). Egevang teaches that when sending the data packet, the 
private address must be translated to a global address (Fig. 2). Therefore, it would have been 
obvious to one having ordinary skill in the art at the time the invention was made to translate the 
private address to a public/global address. One of ordinary skill in the art would have been 
motivated to perform such a modification to use network address translation to use a private 
(non-globally routable) IP address and hence reduce IP address depletion, as taught by Egevang 
(pages 1-3). As modified, Stallings lacks modifying the end point by replacing the first portion 
in the decoded end point v^th the public address in the address header. However, Phifer teaches 
that to avoid problems with locating endpoints in IPSec, one can perform network address 
translation outside IPSec (page 2). In doing so, the inner packet's internal client address is 
replaced with the client's external address. Therefore, it would have been obvious to one having 
ordinary skill in the art at the time the invention was made to replace the first portion with the 
public address in the address header. One of ordinary skill in the art would have been motivated 
to perform such a modification to avoid problems with locating endpoints in IPSec, as taught by 
Phifer (page 2). As modified, Stallings lacks the initial channel being a control channel and 
establishing a data channel between the client and the server using the modified end point. 
However, Bellovin teaches that FTP uses two channels, a control channel and a data channel 
where the control channel is used to negotiate the connection and the data channel uses that 
second connection to transfer data (pages 1-2). Therefore, it would have been obvious to one 
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having ordinary skill in the art at the time the invention was made to enable an FTP server to 
perform the functions described above and to establish a second connection based on the 
modified port command. One of ordinary skill in the art would have been motivated to perform 
such a modification to support the well-known FTP protocol, as taught by Bellovin (pages 1-2). 

24. Claims 5 & 10 are rejected under 35 U.S.C. 103(a) as being unpatentable over Stallings, 
Egevang, Phifer and Bellovin, as applied to claims 1 & 6 above, in further view of "SMTP 
Service Extension for Secure SMTP over TLS" (RFC 2487) by Hoffman. 

Regarding claim 5, Stallings, as modified above, lacks SSL encryption technology as the 
codec. However, Hoffman teaches that SSL is a popular mechanism for enhancing TCP 
communications with privacy and authentication (page 1). Therefore, it would have been 
obvious to one having ordinary skill in the art at the time the invention was made to choose SSL 
encryption technology to encrypt the port command/inner header. One of ordinary skill in the art 
would have been motivated to perform such a modification to enhance communications with 
privacy (encryption), as taught by Hoffman (page 1). 

Claim 10 is substantially equivalent to claim 5. Therefore, claim 10 is rejected under 
similar rationale. 

25. Claims 14-16 are rejected under 35 U.S.C. 103(a) as being unpatentable over Stallings, 
Egevang and Phifer. 

Regarding claim 14, Stallings discloses encoding a port command/original packet 
including a client internal IP address/source address (page 179, Fig. 6.9(b)) and a client port 
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number/port (contained in an TCP/IP header), generating a communication packet having a 
header/outer header and a data payload/original packet, the data payload including the encoded 
port command/original packet (Fig. 6.9(b)), transmitting the packet between a server/destination 
and the cHent/source (page 180), decoding the port command/original packet (page 180, step 3) 
and establishing a data socket (data flow) between the server/destination and the client/source 
(page 180, step 3). The header includes a server external IP address/destination firewall address 
and a server port (TCP header) and a client internal IP address/source address and port (TCP 
header) (pages 180-181). Stallings lacks explicitly overriding the client internal IP 
address/source address within the decoded port command/original packet with the client external 
IP address retrieved from the header. However, Egevang teaches a protocol (NAT) to reduce IP 
address depletion (page 1) (NAT is commonly used today and is incorporated with routers, as in 
Fig, 2). NAT states that when sending a packet from a source behind a router (Stub A) to a 
destination behind another router (Stub B), a packet will contain Stub A's internal address and 
Stub B's global address (Fig. 2). Stub A's local address will be readdressed to the global address 
at Stub A's router and sent to Stub B's global address (Fig. 2). At Stub B's router, the 
destination address will be replaced with Stub B's internal address and forwarded to stub B and a 
similar method is used in the reverse direction (Fig. 2 and page 3). Therefore, it would have 
been obvious to one having ordinary skill in the art at the time the invention was made to 
combine the teachings of Stallings and Egevang to use IPSec with NAT and route the packet 
according to the same transformations as occurred between Stubs A and B. One of ordinary skill 
in the art would have been motivated to perform such a modification because NAT is known to 
reduce the problems associated with IP address depletion (page 1) and because a skilled artisan 
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in network architecture knows of NAT's widespread use and acceptance. Further, Phifer teaches 
that to avoid problems with locating endpoints in IPSec, one can perform network address 
translation outside IPSec (page 2). In doing so, the inner packet's internal client address is 
replaced with the client's external address. Therefore, it would have been obvious to one having 
ordinary skill in the art at the time the invention was made to decode the port command and 
replace the client internal IP address with the client external IP address (NAT translating outside 
IPSec). One of ordinary skill in the art would have been motivated to perform such a 
modification to avoid problems with locating endpoints in IPSec, as taught by Phifer (page 2). 

Regarding claims 15 & 16, Stallings, as modified above, discloses readdressing the client 
internal IP address within the header with the client external IP address at a client firewall and 
readdressing the server external IP address within the header with the server internal IP address 
at a server firewall (Stallings, page 183, Fig. 6.10(b) & Egevang, page 3). 

26. Claims 11-13 are rejected under 35 U.S.C. 103(a) as being unpatentable over Borella in 
view of "Unicast Routing Overview" by Microsoft. 

Regarding claim 11, Borella discloses a packet being sent (outbound) and received 
(inbound) (pages 15-16). The inner IP header shows that when sending a packet from PC2 
(10.0.0.2) to its router (10.0.0.1), the outbound packet contains 10.0.0.2 as the source address and 
10.0.0.1 as the destination address (page 15). Similarly, when the packet is returned from the 
router to PC2, the inbound packet contains 10.0.0.1 as the source address and 10.0.0.2 as the 
destination address (page 16). The ports are addressed in the same reversible manner, depending 
on whether the packet is inbound or outbound (pages 15-16). Microsoft teaches that unicast 
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routing consists of determining a destination address and transmitting an IP packet from a host to 
a destination based on that destination address (page 1). Therefore, during any receive/reply 
TCP/IP transaction, a receiver/second peer receives a packet from a sender/first peer including a 
header/IP header and a port command/packet with TCP ports encoded therein. Upon replying to 
the sender (response), a modified port command is created including a first peer IP 
address/source IP in place of the second peer IP address/destination IP (swapping source and 
destination IP addresses and ports) and a connection is established between the first and second 
peers (data sent from original receiver to original sender). Therefore, it would have been 
obvious to one having ordinary skill in the art at the time the invention was made to use the 
unicast routing, as taught by Microsoft (page 1) to accomplish a receive/reply (standard TCP/IP 
transaction) as taught by Borella. One of ordinary skill in the art would have been motivated to 
perform such a modification to transfer data from a source to a destination, as taught by 
Microsoft (page 1). 

Regarding claims 12 & 13, the claims are substantially equivalent to claim 11. 
Therefore, claims 12 & 13 are rejected under similar rationale. 

Conclusion 

27. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 

a. TCP/IP Illustrated. Volume 1 : The Protocols by Stevens teaches that an IP header 
includes a source and destination address and a TCP header (encoded into the IP header) 
includes source and destination port numbers (page 1), 
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b. The non-patent literature references by Kent (RFC 1827 & RFC 2401), O'Guin, 
Herscovitz and Srisuresh (RFC 2709) are cited for teaching IPSec and it's 
implementation and VPNs. 

c. The non-patent literature references to Srisuresh (RFC 2663 & "Security for IP 
Network Address Translator (ISFAT) Domains) and Tsirtsis et al. are cited for teaching 
NAT and its implementations regarding end-to-end security, 

d- The non-patent literature reference to Allman is cited for teaching FTP 
implementation issues regarding NAT. 

e. The U.S. patent references are cited for teaching network address translation used with 
TCP/IP security and tunneling, and in particular to including coded representations of 
ports/addresses in packets. 

f Patent EP 0 909 074 Al was cited for teaching the use of firewalls with tunneling and 
IPSec. 

f The non-patent references to Aboba, Briggs and Huttunen are cited for teaching 

compatibility issues with NAT, FTP and IPSec and "UPD encapsulation" (doing NAT 

translation on incoming packets). 
28. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Michael J. Simitoski whose telephone number is (703)305-8191. 
The examiner can normally be reached on Monday - Thursday, 6:45 a.m. - 4:15 p.m.. The 
examiner can also be reached on alternate Fridays from 6:45 a.m. -3:15 p.m. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Gregory Morse can be reached on (703)308-4789. 
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Any response to this action should be mailed to: 

Commissioner of Patents and Trademarks 
Washington, DC 20231 
Or faxed to: 

(703)746-7239 (for formal communications intended for entry) 

Or: 

(703)746-7240 (for informal or draft communications, please label "PROPOSED" 
or "DRAFT") 

Hand-delivered responses should be brought to Crystal Park II, 2121 Crystal Drive, 
Arlington, VA 22202, Fourth Floor (Receptionist). 

Any inquiry of a general nature or relating to the status of this application or proceeding should 
be directed to the receptionist whose telephone number is (703) 305-9000. 

Information regarding the status of an application may be obtained from the Patent 

Application Information Retrieval (PAIR) system. Status information for published applications 

may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 

applications is available through Private PAIR only. For more information about the PAIR 

system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 

system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 




MJS 

April 19, 2004 




